Generic build components should be in lfric_build at the top level, not infrastructure/build.

All tools, and nearly all makefiles and PSyclone tools reside in core/infrastructure, while lfric_build is a basically empty directory (containing an unused scripts and tests for it). Wouldn't it be easier for all developers to maintain that mapping (which also keeps the root directory one directory cleaner)?

Is there a document outlining these 'should be' statements? I get caught up frequently by something that is envisioned to work differently, which causes me a lot of wasted time. And I would also like to understand the reasoning behind some of these rules.

This gives the correct input arguments. Presumably it would be a bad thing to call the run() method on this class. In which case, overriding it with one which throws an exception should provide a bit of safety. You're all ready calling it via super() below so that should be unaffected.

I can't do that. First of all, nothing bad will happen (as long as the caller knows what they are doing ;) ), and it might help with testing new features for (say) templaterator.

But mostly (for now at least): I can't do that, tool.py calls super().run(...) itself, e.g. during availability checking, which would then abort, making all tools as not available.

Generic build components should be in lfric_build at the top level, not infrastructure/build.

Same question: why. Templaterator, ... are all what I would call generic build components, and the are under infrastructure/build. Why make it more confusing for the user?

Providing an alternative entry point with the correct arguments is good. Please override run() with a version which throws an exception to prevent accidental calling.

This will require calls to it within this class to make use of super().

Same thing, can't do since tool.py calls super().run(..).

What is this for. We expect external tools like Rose Picker to be on the path. If it is, then it's there and can be called. If it isn't, that's an error and the build should stop. I don't understand the need for all this.

Fair point. This script goes back to a time where it wasn't available, and we left it in (assuming it could be useful to easily test new versions of rose picker), but I agree, this is all kind of useless, and I have significantly cleaned up the code here.

This function should probably return the Path to the files which are generated. Thereby removing the requirement for calling functions to guess.

There's a general problem with there being nothing magical or required about "full debug" or any of the other "profiles." However, specifically there are also integration tests which don't seem to have been covered.

Having a function called setup_cray which calls a function called setup_cray can only ever cause confusion. That goes for all the others. Why does this facade exist?

Part of the user experience we want to have is that building is always achieved through the same procedure. Specifically, changing into a project directory and issuing a command. The same command. So please rename all build scripts to build. Note that we do not add the .py extension to executables.

I notice that the build executable implements a class named after the project being built yet that class is passed the project name on initialisation. Why not pass that name from the constructor?

class ProjectBuild(LFRicBase):
    def __init__(self):
        super().__init__(name="project")
  
if __name__ == '__main__':
    builder = ProjectBuild()